Die Integration von Verifikation und Test in Übersetzungssysteme

In dieser Arbeit wird die Architektur für einen Compiler vorgestellt, der die Korrektheit der übersetzten Quellen als Teil des Übersetzungsvorgangs überprüfen kann. Dabei soll es möglich sein, verschiedene Methoden, wie etwa formaler Test und formaler Beweis, einzusetzen, um die Korrektheit nachzuweisen. Ein vollautomatischer Nachweis ist sehr aufwendig und häufig auch gar nicht möglich. Es ist also nicht praktikabel, aus Spezifikation und Programm die Korrektheit automatisch abzuleiten. Wir erweitern daher die Sprache um Korrektheitsnachweise (justifications), die der Benutzer in den Quelltext einfügen muß ("literate justification"). Je nach gewählter Methode muß der Benutzer den Korrektheitsnachweis mehr oder weniger genau ausführen. Durch die Einführung der Korrektheitsnachweise muß der Übersetzer Beweise nur noch überprüfen anstatt sie automatisch abzuleiten. Die Überprüfung der Korrektheitsnachweise kann in den Übersetzer integriert werden oder an ein externes Werkzeug delegiert werden. Ein externes Werkzeug erlaubt die Einbindung bereits existierender Werkzeuge, aber auch eine Neuentwicklung eigener Werkzeuge ist möglich. Wir zeigen am Beispiel eines taktischen Theorembeweisers, daß eine Eigenentwicklung nicht unbedingt aufwendiger ist als die Anpassung eines vorhandenen Werkzeugs. Um Tests während der Übersetzung durchführen zu können, muß ein Interpreter zur Verfügung stehen. Die Ausführung ungetesteten Codes birgt allerdings auch Sicherheitsprobleme. Wir diskutieren verschiedene Möglichkeiten, mit diesem Problem umzugehen. Der Korrektheit einer Übersetzungseinheit entspricht in der Semantik die Konsistenz einer algebraischen Spezifikation. Wir betrachten zwei Beweismethoden: zum einen durch Konstruktion eines Modells und zum andern durch Nachweis einer korrektheitserhaltenden Relation. Die Beweisverpflichtungen ergeben sich zunächst aus der Beweismethode, außerdem werden Beweisverpflichtungen eingeführt, um die Korrektheit von zusammengesetzten (modularen) Programmen zuzusichern. Die in dieser Arbeit beschriebene Architektur ist prototypisch implementiert worden. Dazu wurde das Opal-System um Elemente zur Spezifikation und zur Beschreibung von Korektheitsnachweisen erweitert. In der Arbeit werden einige kurze Beispiele vorgeführt. Der Opal/J-Prototyp ist seit Version 2.3e Teil der Opal-Distribution.In this thesis we present a compiler architecture that enables the compiler to check the correctness of the source code as part of the compilation process. It allows to perform these correctness checks with different methods, in particular formal testing and formal proof. A fully automated check is very expensive and often impossible. Hence, it is not feasible to check correctness automatically with the help of specification and implementation. We extend the programming language by (correctness) justifications that the user must insert into the source code ("literate justification"). Depending on the chosen justification method the user must work out the justification in more or less detail. The introduction of justifications changes the compiler's task from deriving a correctness proof by itself to checking a correctness proof provided by the user. The correctness check for justifications can be integrated into the compiler or delegated to an external tool. An external tool allows the integration of existing tools but the development of specialized tools is also possible. The example development of a specialized tactical theorem-prover shows that the development of a specialized tool is not necessarily more expensive than the adaptation of an existing tool. For test execution during the compilation an interpreter must be available. The execution of untested code causes security risks. We discuss different possibilities to deal with this problem. The correctnessof a compilation unit corresponds to the consistency of an algebraic specification. We study two proof methods: either by construction of a model or by establishing a correctness-preserving relation. The proofo bligations result from the proof method, in addition proof obligations arei ntroduced to ensure the correctness of modular programs. The compiler architecture described in this thesis has been prototypically implemented. The Opal system has been extended with language elements to denote specifications and (correctness) justifications. The thesis presents some short examples. The Opal/J prototype is part of the Opal distribution since version 2.3e

A Pragmatic Approach to Software Documentation

We present an approach for designing a literate programming tool that, in addition to covering the technical issues, especially targets the acceptance of the documentation system by the program developer. We then describe the DosfOp documentation system for the Opal language, which was developed in line with these design principles. Finally, we discuss experiences with the system from a user's and from an implementor's point of view. 1 Introduction The need to document software products as soon as they have evolved beyond the stage of mere playthings or examples is evident to most software users and even to most software developers. Nevertheless, documentation is often not available or is outdated, either because the development of actual running software is more important and is easier to check for the customer than the quality of the documentation or because the job of keeping the documentation up to date is too arduous. Documentation systems can help to combat the second problem. T..

OPAL: Design And Implementation of an Algebraic Programming Language

this paper we illustrate some principles of algebraic programming. Moreover, we introduce the language Opal, sketch its compilation strategies, and point out some challenges for further research in the area of algebraic programming languages

Realizing Sets by Hash Tables: How to do it in KORSO

One of the crucial operations on the path from specification to implementation is the modification of data structures. In this paper we demonstrate how this task can be accomplished constructively and, in particular, how it can be done within the Korso methodology. 1 Introduction One of the central activities in the course of the development of a software system is the realization of "abstract" data structures by "more concrete" ones. Originally, this task was only considered in the specific case, where an abstractly specified data type was "implemented" in terms of a concrete data type of a given programming language. But it soon became clear that the same principle also applied in situations where the "concrete" type was actually only specified algebraically. Thus, implementation became a step-by-step process, leading through several stages of algebraic specifications -- which were, however, more and more concrete -- until one eventually arrived at the level of a given programming ..